System and Process for Producing a Two-Layer Document, and a Two-Layer Document Produced Accordingly

ABSTRACT

The present invention relates to a system for the preparation of an extended, two layer document, said extended document forms a single package which comprises a text document and a meta-data layer program attached to it, said system comprises a meta-data layer editor, which in turn comprises: (a) a document connector module for receiving a text document, and for parsing the document to document elements; (b) rules editor for defining rules concerning the content of each meta-data layer element, rules concerning to the form of appearance of each meta-data layer element, and action rules concerning conditions for activation of meta-data layer elements, wherein meta-data layer elements correspond to selected document elements of said locked text document; (c) program generator for generating from said rules an intermediate meta-data layer program; and wherein said system further comprises at least one converter for receiving a copy of said locked document and also receiving said intermediate program from said program generator, and for converting the same to said two layer extended document.

FIELD OF THE INVENTION

The field of the invention generally relates to systems and methods forthe production of electronic documents, and to viewers for displayingsaid electronic documents on electronic displays. More particularly, theinvention relates to a system and method for the production of atwo-layer electronic document, wherein the electronic documentcomprises: (a) a first layer being a “locked” document, such as aconventional PDF document; and (b) a second layer which includesadditional visual information relating to specific portions of the“locked” document. This layer provides meta-data, or additional helpthat is not necessarily a part of the original locked document, butcomplements and supports the user interaction with the originaldocument, or provides additional business values.

BACKGROUND OF THE INVENTION

In today's working environment, documents are published in severalcommon formats, mostly using HTML, .DOC, .PS and Adobe's PDF formats.The ability to send such documents to recipients over the Internet andto display them at the recipient side by means of free software viewersmakes the documents publishing and their electronic transfer extremelyappealing. Among the free viewers, the leading ones are the webbrowsers, such as the Internet Explorer and Mozila Firefox, and for PDFthe most common browser is the Adobe Acrobat Reader.

The PDF format has been widely accepted as a means for sending pseudo-or fully authenticated electronic documents. In order to generate anAdobe's PDF file, a PDF writer is used. The PDF writer receivesdocuments that have been previously edited in various formats, such asWord, Excel, or HTML, and can be easily converted to the PDF documentformat. Practically, any application that provides “print” capabilitiescan be configured to generate a PDF file, instead. A PDF formatteddocument is an electronic file, which can be viewed electronically usingthe appropriate viewer, such as Adobe's Reader, and is displayed exactlyas it would have been if printed. Moreover, a document in PDF format isessentially locked, and the document cannot be altered after, itsconversion to PDF. Electronic signature can be embedded in the PDF fileas well, to provide an improved assurance that no unauthorized changeshave been made to the document.

In one example, and with the widespread availability of PDF viewers atthe client sides, many companies send by email to their customers billsin a PDF format, either by attaching the PDF file itself or a link tothe bill which is stored at the company web site, or FTP server. Thiselectronic mailing alternative reduces the handling costs and standardmail expenses, and further, it attracts the customer back to the companyweb-site.

While HTML-based documents and their browsers naturally supportinteractive mode, and JavaScript interpretation, PDF has only recentlybegan to provide support for JavaScript within the viewer. Accordinglyalso PDF documents may become interactive.

In still another aspect, customers typically receive from the companyforms, in which several fields need information insertion. The user inturn can fill information within the form fields, for submission back tothe company, all of which, through PDF-based forms.

In another, more general alternative, documents of various types (WORD,EXCEL, HTML, etc.) that are sent to recipients have become complex andinteractive: The recipients view documents which have a complex internalstructure, with multiple internal dependencies and links. Some fieldscontain data which is derived from several other fields; other fieldsare interactive, where the recipient can fill information for submissionback to the company. As said above, this latter option is obvious forHTML, but is possible also for PDF, Excel and Word documents.

Presently, the publishing (i.e., forming the document and sending to arecipient) mechanism of documents provides only a single layer. It doesnot provide a mean for editing and then publishing the content of saidadditional layer. Further, while it is possible to program suchadditional layer for any of the needed formats, it is not possible togenerate such a layer in a manner which is consistent over all thedocument formats that are mentioned so far. Furthermore, the only waywhich is presently available to provide “help”, and content-sensitiveservices to a PDF document involves JavaScript programming. There is nonon-programming manner to provide such a content-sensitive or help(meta-data) layer. Accordingly, in order to include explanations for howto fill the various fields of a PDF document such as a form, thedocument supplier is presently required to program said “meta-data”fields using JavaScript.

Although, as said, PDF viewers support the interpretation of associatedJavaScript (such as conditional functions with multiple texts thatappear on a separate layer) with specific fields of a generated PDFdocument, the only way presently existing to generate this associatedJavaScript programs is to program these additional capabilities.Typically, document publishing tools focus on the capabilities togenerate a high quality graphical object, sometimes with multiplegraphical layers, and with precise content. However, none of said toolsprovides an interface which includes a non programming editorial toolhaving graphical capabilities (for example, similar to those that are asprovided for generating the basic document, i.e., the document beforepublishing) also for the purpose of generating a meta-data layer (forexample, a layer for the purpose of adding help features). Furthermore,the prior art does not provide a single, non programmable editorial toolwhich is capable of producing a single meta-data layer template, whichcan then be transformed and attached to a same document, but in severalformats such as DOC, PDF, EXCEL, HTML, etc.

Each document is edited using its special-purpose editor (e.g. for HTMLthere are HTML editors such as FrontPage™ by Microsoft™. For Worddocuments that generate .DOC documents the typical tool is MicrosoftWord™.). Accordingly, presently if one wishes to apply meta-data to allformats, as this meta-data reflects business rules, there is a need tore-program this meta-data separately for each specific application(document) format. This causes major inconsistencies and preventsactually using this additional layer. Since in the prior art tools forgenerating PDF and HTML documents there is no way to ensure that a samemeta-data (such as said help features) which are programmed andgenerated once, can be used for both HTML, DOC and PDF, as these toolsare specially tailored for each of said tools separately, it is desiredto provide a single meta-data editor which is suitable for creating saidmeta-data layer once for all said various documents formats.

It is an object of the present invention to provide a non-programminginterface for producing a document meta-data layer, which will beattached to the document and published according to the document format;

It is a particular object of the present invention to provide a tool forautomatically associating help messages and rule-based content-sensitivemeta-data to PDF documents;

It is still another object of the present invention to provide an editorfor drafting and attaching to specific sections or fields of a PDFdocument meta-data comments within an additional layer, wherein saidmeta-data comments are optionally or selectively exposed to the userupon viewing the PDF document. The use of said editor does not requireany programming capabilities from the editor user.

It is still another object of the present invention to provide anon-programming tool for generating content sensitive meta-data layer,i.e., a layer whose content depends on the content of the main document.

It is another object of the present invention to allow for editing themeta-data content once for all document formats, and then to transformthe content to the desired program format according to the specificneeds of that document format.

Other objects and advantages of the present invention will becomeapparent as the description proceeds.

SUMMARY OF THE INVENTION

The present invention relates to a system for the preparation of anextended, two layer document, said extended document forms a singlepackage which comprises a text document and a meta-data layer programattached to it, said system comprises a meta-data layer editor, which inturn comprises: (a) a document connector module for receiving a textdocument, and for parsing the document to document elements; (b) ruleseditor for defining rules concerning the content of each meta-data layerelement, rules concerning to the form of appearance of each meta-datalayer element, and action rules concerning conditions for activation ofmeta-data layer elements, wherein meta-data layer elements correspond toselected document elements of said locked text document; (c) programgenerator for generating from said rules an intermediate meta-data layerprogram; and wherein said system further comprises at least oneconverter for receiving a copy of said locked document and alsoreceiving said intermediate program from said program generator, and forconverting the same to said two layer extended document.

According to the invention said one or more converters are locatedinternal or external of said meta-data layer editor.

In one embodiment, when a converter is located within said meta-datalayer editor, it is used to output an extended document during earlystages of the meta-data layer design. In that case, the input to themeta-data layer editor is generally a full text document.

Preferably, the system further comprises a GUI for interfacing with themeta-data layer creator.

Preferably, said meta-data layer editor is used off-line by a meta-datalayer creator;

In a preferred embodiment, the system is used for serially preparingplurality of extended documents one at a time, wherein each document iscustomer specific, which further comprises: (a) a document processor forpreparing one at a time an original customer specific document, saidprocessor being in communication with a customer database and it alsoreceives a document template, document preparation rules, and additionaldata, said original customer specific document being conveyed to alocking-publishing unit; (b) locking-publishing unit for receiving, oneat a time, said original customer specific document, and for producing alocked document; (c) a meta-data layer processor for receiving one at atime said published locked document and said intermediate meta-datalayer program, and using a converter, producing said two layer extendeddocument.

In one embodiment, the converter which is used by the meta-data layerprocessor for producing said two layer extended document is external tothe meta-data layer editor.

In one embodiment, the document which is used as an input to the editorduring later stages of the meta-data layer design is a template lockeddocument.

The invention also relates to a system for producing plurality of formatversions of extended documents, wherein each of the one or moreconverters, whenever used, receives said intermediate program andplurality of format versions of documents, and it converts them toplurality of format versions two layer extended documents, all abidingthe same set of meta-data rules, for correlated objects within thevarious versions.

Preferably, the meta-data layer within the extended document is aprogram coded in a software language which is suitable for activation bythe corresponding viewer which displays said two layer documents.

Preferably, when the extended document is a PDF document, said softwarelanguage is a first type of Java Script, when the extended document isan HTML document, said software language is a second type of JavaScript, when the extended document is a WORD document, said softwarelanguage is Visual Basic, and when the extended document is of anotherformat, said software language is in another language which is suitablefor activation by the viewer.

Preferably, the rules and actions together determine customer specificconditions for activation and corresponding content of each meta-datalayer element, when the extended document is displayed by acorresponding viewer.

Preferably, the meta-data layer elements have a form of pop-up balloons.

In one embodiment of the invention, each of the extended documents isconveyed to a corresponding customer by email, and is viewed by thecustomer by means of a corresponding viewer. In another embodiment, eachof the extended documents is saved within extended documents database atthe company, and only a link to the respective document is sent to thecustomer by mail.

In one embodiment of the invention, the extended document is a bill, andthe document processor is a bill processor.

Preferably, the meta-data layer of the extended document displays to theuser who views the document a corresponding indicator, which when theuser puts his mouse marker next to said indicator, the activation of acorresponding meta-data layer element occurs.

In a preferred embodiment, the extended document is a PDF extendeddocument. In that case, the extended document is a two-layer PDFdocument, the locking-publishing unit is a PDF distiller. In anotherembodiment, the extended document is a WORD extended document. In stillanother embodiment, the extended document is an HTML extended document.In still another embodiment, the extended document is an EXCEL extendeddocument.

In an embodiment of the invention, the meta-data layer editor and themeta-data layer processor are included within a meta-data layer manager.

Preferably, upon viewing of said extended document at a user viewer, themeta-data layer is also activated, and it selectively displays themeta-data elements to the user.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1 is a flow diagram illustrating a process for preparing a PDFlocked document according to the prior art;

FIG. 2 is flow diagram illustrating a process for preparing PDF lockedbills by a company, for mailing the same to customers according to theprior art;

FIG. 3 is a flow diagram illustrating a process for preparing anextended PDF extended document, which includes a locked PDF document anda meta-data layer, according to the present invention;

FIG. 4 is flow diagram illustrating in more detail a process forpreparing by a company of an extended PDF bill, which includes a lockedPDF bill and a meta-data layer, and mailing the same to a customer,according to the present invention;

FIGS. 5B, 5C, and 5D, provide an example of an extended PDF bill, as isviewed in various view stages by a customer. FIG. 5A shows a view of thesame bill without the meta data layer, as is conventional;

FIG. 6A is a block diagram illustrating the structure and operation ofthe meta-data layer content editor, when producing a single formatextended document; and

FIG. 6B is a block diagram illustrating the structure and operation ofthe meta-data layer content editor, when producing plurality of formatversions of an extended document; and

FIG. 7 if a general flow diagram which describes the process forproducing plurality of format versions of an extended document.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

As is common in the art, a PDF file is a “locked” file which isconstructed either from a document file which has been initiallyproduced by means of an editor (e.g., a word processor such as WORD, oranother editing program such as Excel, Power Point, etc.), or by meansof a scanner which optically scanned the original document. There areseveral software packages that can produce a PDF file, for example,Adobe's Acrobat Writer, Adobe's Acrobat Distiller, or compatibles. Thelocked PDF file is essentially a true image of the original document.When the locked PDF file is opened by means of an appropriate viewer(such as Adobe's Acrobat Reader, or compatible), the image of thedocument is displayed to the user, exactly as produced. The term“locked” intends to indicate that the creator of the file is the onlyowner of the original file content. This is easily achieved by using PDFformat that can be viewed, but cannot be modified. The locking of thePDF file therefore commonly serves the purpose of electronically storingand electronically transferring a true image of the original document.It should be noted that the present invention relates to any locked fileformat (such as HTML, DOC, XLS, etc.), whether scanned or otherwiseconstructed). For the sake of brevity, however, the description mostlyrefers to a locked file which is originally produced by means of anediting program (such as WORD), and is later converted to a locked PDFformat document.

It should be noted that although the present invention, as described,mostly refers to a “locked” PDF format file (which is the most commonformat for locked documents), other file formats can also be consideredas “locked”, particularly when one may need, if at all possible, specialtools for opening the file for editing. For locking a file, one may alsouse watermarking, electronic signature, or other locking mechanisms toallow just content viewing of the document but no content modifications.Therefore, it should be noted that the present invention refers also toany such type of “locked” file, not only to a PDF “locked” file. The useof the invention in conjunction with PDF format documents is used hereinonly as one example.

As locking is sometimes not critical, more open formats can be relevantas well. In particular, HTML, XLS and DOC documents are examples of suchrelatively open formats. These formats still support separation betweenthe core content (the locked layer), and other layers.

FIG. 1 shows a typical prior art two-stage system 200 for producing aPDF locked file from an editing program. In a first stage 201, adocument file is prepared by means of an editor, such as a WORD editor,an HTML editor, Power Point editor, Excel editor, etc. When the editingof the document by editor 201 is completed and the file is ready in acorresponding DOC, HTML, XLS or JPG or GIF format, the file istransferred to a PDF distiller 202 for publishing, where the unlockeddocument is converted to a PDF locked document 203.

As previously mentioned in the “Background of the Invention” above, ithas become common for companies to issue and electronically senddocuments such as bills to their customers in PDF locked format (oralternatively, a corresponding link to said bill which is stored at thecompany site). FIG. 2 illustrates in a block diagram form a typicalprior art system 300 for issuing and sending bills in PDF format tocustomers. The system comprises bills processor 301, whose purpose is toproduce a bill in a locked format for each specific customer. Theoperation of the bills processor 301 is governed by bill generationrules 316 which may be prepared by accounting department, customermanagement team, or marketing department, and may be updated from timeto time. Said rules 316 may determine the date to issue the bill, aminimum charge for issuing a bill, specific bill format to specifictypes of customers, additional content associated with the bill, etc.The bills processor 301 receives inputs from essentially three sourcesas follows: (a) a bill template storage 312 which contains a basictemplate for the bill, or a storage of various templates to select from;(b) a customer database 313 which contains the current billing data ofthe relevant customer; and (c) additional general data 314 that has tobe included in all bills (e.g., images, corporate logo, etc.).

Having the required inputs from said three resources 312, 313, and 314,the bills processor 301 produces a bill in some unlocked format. Thefile of the bill in the unlocked format is then conveyed to a PDFdistiller 302 (or another compatible unit) for publishing. The PDFdistiller 302 produces a PDF locked document 303, which reflects theexact image of the bill. During this process an explicit signature maybe added by means of electronic signature or watermarking process (notshown).

The locked PDF bill is stored in bills storage 307. Then, a copy of thelocked PDF bill is sent 306 to the customer by email, or alternatively,only a link to the bill in said storage 307 is sent by email to thecustomer.

As said, the Adobe's Acrobat Writer, and Adobe's Acrobat Reader are nowprovided with a Java Script module, enabling the attachment of a JavaScript program to a locked PDF file. The Adobe's Acrobat Reader (i.e.,viewer), accordingly, is now provided with a corresponding Java Scriptsupport module for reading and executing (interpreting) said attachedJava Script program if and when attached to a PDF file.

The following example of FIG. 3, which describes one usage of thepresent invention, relates to a visual content editor for adding a JavaScript meta-data layer to a PDF locked document, therefore producing anenhanced PDF document. According to this example, the Java Script layeris added to the locked document after its publishing. In similar theprior art system of FIG. 1, the system of this example comprises aneditor 401 for editing a typical document, and a PDF distiller 402 (orequivalent) which publishes the document in PDF locked format. Insimilar to the system of FIG. 1, the product of the PDF distiller 402 isa PDF locked document 403. The system of this example further comprisesa meta-data layer manager 600 which includes editor for enteringdefinitions of the metadata, which operates on said PDF locked document403, and adds to it a Java Script layer of meta-data. The Java Scriptlayer is attached to said PDF locked document 403, forming a package 405of a PDF locked document 405 a and a Java Script meta-data layer 405 b.Hereinafter, said package of a PDF locked document and a Java Scriptmeta-data layer will be referred to as “extended PDF package”. Saidextended PDF package can now be electronically conveyed to anotheraddress in any conventional manner, such as by email. Similarly, formore general cases when other locked file formats are used, an “extendedpackage” is created by meta-data layer manager 600. The format of themeta-data layer 405 b depends on the file format and on thecorresponding file viewer which is used. The essence of said meta-datalayer and the manner of operation of said meta-data manager 600 will bedescribed in more detail hereinafter.

One property of the meta-data layer manager 600 should be noted.Although for PDF documents its output is a Java Script add-on program tothe locked PDF document, for other file formats, an add-on program ofappropriate programming language must be generated. For example, forHTML document which is normally viewed by an Internet Browser, adifferent Java Script program must be generated. In another example, fora WORD viewer, a Visual Basic add-on program must be generated.

FIG. 4 illustrates in block diagram form a system 500 for automaticallyissuing extended PDF bills, according to an embodiment of the presentinvention. By “extended PDF bill” it is meant to refer to an electronicbill which has a form of extended PDF file, i.e., a bill file whichcomprises both a locked PDF document and a JAVA Script meta-data layerattached to it. The units 501, 502, 512, 513, 514, and 516 areessentially the same, and perform the same function as units 301, 302,312, 313, 314, and 316 respectively of FIG. 2. Therefore, for the sakeof brevity the functionality of said units will not be repeated here indetail. In addition, the system 500 comprises a meta-data layer manager600. The meta-data layer manager 600 comprises meta-data layer processor520 and meta-data layer content editor 521, for the preparation of ameta-data layer specific to each bill. For its operation, the meta-datalayer processor 520 uses as input the meta-data program 522, which aretypically pre-prepared and pre-updated generally by one or more of: acustomer management team, a marketing team, etc. Said rules may define,for example, content sensitive generation rules: if the value of thetotal amount to pay in the bill is above $Y, generate a meta-data ofform “A”, otherwise generate meta-data of form “B”. Various templatesfor the meta-data layer are initially prepared by one or more of saidteams by means of meta-data content editor 521. As before, the billsprocessor 501 prepares the bill, and sends it to PDF distiller 502,which in turn issues a locked PDF file 503 a of the bill. The meta-datalayer processor 520, which as said uses the input program 522, similarlyoperates in communication with customers database 513, and prepares aJava Script meta-data layer 503 b for each bill, which is based on theone or more templates as prepared by means of meta-data layer contenteditor 521, and which is specific to each customer. For example, basedon the specific data of the customer (such as his previous backgroundbilling, the current bill value, etc.), the meta-data may includeplurality of content elements, such as an element with a specific offerto the client, a help element which explains a specific data field (forexample, a billing line) within the bill (which as said may also bespecific to a customer, or even may depend on the specific customerfamiliarity level with the company bills), or it may provide him withanother element that contains a link to a specific location within thecompany website to find more detailed explanations, etc. As in thesystem of FIG. 2, the extended PDF bill 503 (which includes the PDFlocked bill 503 a and the Java Script meta-data layer 503 b) or a linkto its copy as stored in the company bills storage 507, is conveyed tothe customer by email 506. It should be noted that the meta-data layereditor may be either dedicated for a single specific format, or it maybe generic for plurality of formats, as will be described later.

According to the present invention, upon activation of the PDF viewer bythe customer, the JavaScript based meta-data layer is activatedsimultaneously with the locked PDF document. The meta-data layer, whichis preferably divided into plurality of elements, is preferably notshown entirely on the screen. For example, a specific meta-data elementmay be positioned near a predetermined specific data (for example, aline or field) of the locked document to which it relates, and may beactivated to be viewed by the user only when desired. For that purpose,the meta-data layer may include and display a predefined indicator (forexample, “?”), for indicating that a further help or data can beprovided. The user, when positioning his marking device (such as hismouse) on a specific marker, can activate the display of thecorresponding meta-data element. The activation rules of each meta-dataelement are part of the meta-data layer rules.

FIGS. 5A, 5B, 5C, and 5D provide an example for an extended PDF billaccording to an embodiment of the present invention. FIG. 5A shows theoriginal PDF bill, as is conventionally viewed by a PDF viewer. FIG. 5Bshows the same bill, this time with the additional JavaScript layer,which displays several “?” indicators 610 a-610 d at specific locationsof the bill. The user, when positioning his pointing device on aselected “?” indicator of the Java Script layer, activates acorresponding meta-data element, (in this case of a “balloon” type) ofmeta-data which appears and assists the user in understanding thedocument, or portions thereof, or refers him to some more help in thecompany web site. FIG. 5B shows the bill of FIG. 5A, when the balloon611 a relating to “?” indicator 610 a is activated. This specificballoon is initially visible, in order to attract the user attention tothe new capability of the invention. FIG. 5C shows another balloon 611 dwhich in this case is design to attract the user to an additionalmarketing initiative of the company. FIG. 5D shows still another balloon611 c, which corresponds to “?” indicator 610 c, and which is designedto guide the user in case of an address change.

FIG. 6A provides in block diagram form a structure of one embodiment ofmeta-data layer content editor 521, which prepares a meta-data layer fora PDF document, and which can then be attach said layer to the documentto form a PDF extended file. More specifically, this embodiment of themeta-data content editor 521 enables the user to define the elements ofthe meta-data layer (which as said may have the form of balloons thatare activated when desired), the balloon contents and locations, and therules which govern their appearance. Moreover, this is an editor, whichcan produce a meta-data program which is suitable for attachment to aPDF document. As the editing process of editor 521 is performedoff-line, there are two manners of operations with editor 521. In afirst manner, the input to the editor is a full PDF document. In thatcase, the output of editor 521 is an extended PDF document. This firstmanner of operation is generally useful during the early developmentstage of the meta-data layer. A second manner of operation with themeta-data content editor 521, which is performed during the later andfinal stages of the meta-data layer development involves inputting tothe editor 521 a PDF template, and outputting a PDF program which isused during the online process flow to be attached to respectively tothe various different PDF documents, for example to the various bills ofthe different company customers.

The editor GUI 990 is the interface with the meta-data content creator(hereinafter the “creator”) at the company who defines the variousaspects relating to the document dependent meta-data layers. This GUI990 enables him to prepare the meta-data layer, and to define the rulesassociated with the meta-data, and their actions. The scheme of FIG. 6Aassumes that the creator wishes to obtain a meta-data layer for adocument which has been saved in PDF format. The document, in PDF formatis inputted into PDF connector module 610 (which in its more generalterm is also referred to herein as “document connector module”). The PDFconnector module 610 parses the PDF document according to the documentelements included in it (a document element is a specific data fromwithin the document), and it builds an internal representation such as atable which summarizes the elements of the document. The table alsoincludes for each document element, among other data, the locationcoordinates of each element. A document element within a bill may be,for example, the field of the “total to pay”. The location coordinatesindicate the location of that field within the PFF document. In anotherexample, a document element may be the address of the customer, and thelocation coordinates of this element are also provided. The locationcoordinates enable identifying the elements, and later on the extractingof the value of the document element (values such as $133, LA, etc.).Other characters of the elements, such as the color, the text, the textsize, etc. may also be saved in the table. Having the table, one or moremeta-data rules may be defined for each selected element. The rules andactions are defined by the user using rules editor 920 and actionseditor 930 respectively. Once the creator completes editing the rulesand the actions, the combination of all the information (objectrepresentation, rules and actions) needs to be transformed into aprogram—which is then saved in the meta-data program storage 522 (FIG.4) which is external to meta-data layer content editor 521. Aspreviously discussed, the rule may indicate that “if the value ofelement Y is Z, then perform action X”. The actions as defined by meansof action editor 930 may indicate, for example, that a specific balloon(which is one type of a meta-data element) with a specific contentshould be activated, that a link should be displayed, or that a contentwithin a specific balloon should be changed as indicated by a respectiverule, etc. Furthermore, the actions may indicate how the balloons (orother meta-data information) may look like, for example in terms of itsshape, color, size, etc.

The output generator 945, or more particularly the Java Script programgenerator 940 of the output generator, receives as an input the documentitself in PDF format (from PDF connector 910), the rules associated withthe document as defined by rule editor 920, and the correspondingactions for each of the rules as defined by actions editor 630. As said,there are two manners of operation in which the editor is used,depending on the inputted document. If the inputted document is a fulldocument, for example, a specific bill which includes all the specificvalues in all fields, the output 955 from unit 521 is ready foroperation extended document. As said, such manner of operation is usefulgenerally in early stages of the meta-data layer definition. If,however, the inputted document is a template document, for example, abill template which does not include specific values for the bill fields(such as the specific customer name, his address, and all other valuesspecific to a specific bill), the output 956 from unit 521 is a JavaScript intermediate program.

For the case where the inputted document 960 relates to a full document(in contrast to a document template), the operation of the outputgenerator 945 is preferably performed in two phases, a first phase byJava Script program generator 940, and a second phase by converter 950.Upon receipt of the document from the PDF connector module 910, thedefined rules from rules editor 920, and the corresponding actions fromactions editor 930, the Java Script program generator 940 produces aJava Script program which describes all the activities expected from themeta-data layer, based on the predefined rules and actions, and withrespect to the corresponding document. Said Java Script program 970 asproduced by Java Script program generator 940 is provided into converter950. Converter 950 attaches said Java Script program to the PDF file,thereby to produce the extended documents. As said, the above describedtwo-phase process of the output generator 945 is suitable for the earlystages of the editing of the meta-data layer, as it operates on aspecific, full inputted document. The output of the two phase process ofmodule 645 is not suitable for real time creation process of extendedbills, as these bills are based on templates, to which specific data arefed in real time, according to the currently processed bill. For thatpurpose during a later stage of the editing process, the creator workson a template document which is inputted to PDF connector module 960(this may be the same specific document, treated as if it was atemplate). The inputs to the output generator 945 are the samedescribed. However, during said latter manner of operation, only thefirst stage (i.e., of the Java Script program generator 940) is used.The Java Script program 956, as created, is outputted to the meta-datalayer processor 520 (FIG. 4). The meta-data layer processor 520 in turnalso comprises a converter (not shown) essentially identical to theconverter 950 of the meta-data layer editor 521, as described withrespect to FIG. 6A. As previously said with respect to FIG. 4, themeta-data layer processor 520, produces in real time one at a time thevarious customer specific bills (or other documents) from templates,using the data specific to each customer, as stored in database 513.Having a specific bill (or another specific document, as is the case) onone hand, and the Java Script program 956 on the other hand, theconverter which is within the meta-data layer processor 520 produces theextended bills (or documents) one at a time. In other words, it producesone at a time a specific extended PDF bill (or document), whichcomprises a PDF document to which a corresponding Java Script program isattached to produce assistance in a different layer and enrich theunderstanding of the layer by the receiving customers.

FIG. 6B provides in block diagram form a structure of a genericmeta-data layer content editor 521, which is capable of preparing ameta-data layer once for a specific document, and which can then beattached to the document to form an extended file in one specificformat, or in more than one format as selected. More specifically, themeta-data content editor 521 enables the user to define the elements ofthe meta-data layer (which as said may have the form of balloons thatare activated when desired), the balloon contents and locations, and therules which govern their appearance. Moreover, and as said, this is ageneric editor, which can produce an intermediate meta-data programonce, which can then be transformed to various format dependentprograms, that are suitable for attachment to various types of formatdocuments and thereby to produce plurality of format versions ofdocuments. Furthermore, it should be noted that the editing process ofeditor 521 is performed off-line.

The editor GUI 690 is the interface with the meta-data content creator(hereinafter the “creator”) at the company who defines the variousaspects relating to the document dependent meta-data layers. This GUI690 enables him to prepare the meta-data layer, and to define the rulesassociated with the meta-data, and their actions. The scheme of FIG. 6Bassumes that the creator wishes to obtain a meta-data layer for adocument which has been saved in several formats (for example a documentsaved in PDF, HTML and WORD. Hereinafter, the various formats of a samedocument will be referred to as “versions”). The versions of thedocument, as saved in said several formats are inputted into technologyconnectors module 610. The technology connectors module 610 parses eachof the versions of the document according to the elements included inthem, and builds a table which correlates between the document elementsof the different versions (as said the various versions relate to a samedocument). The table also includes for each document element, amongother data, the location coordinates of each element. An element withina bill may be, for example, the field of the “total to pay”. Thelocation coordinates are provided for each version and they indicate thelocation of that field within each document version. In another example,a document element may be the address of the customer, and the locationcoordinates of this element are also provided. The location coordinatesenable identifying the elements in each version, and later on theextracting of the value of the document element (values such as $133,LA, etc.). Other characters of the document elements, such as the color,the text, the text size, etc. may also be saved and correlated in thetable. Having the table, one or more meta-data rules may be defined foreach selected document element. The rules and actions are defined by theuser using rules editor 620 and actions editor 630 respectively. Oncethe creator completes editing the rules and the actions, the combinationof all the information (object representation, rules and actions) needsto be transformed into a program—which is then saved in the meta-dataprogram storage 522 (FIG. 4) which is external to meta-data layercontent editor 521. As previously discussed, the rule may indicate that“if the value of element Y is Z, then perform action X”. The actions asdefined by means of action editor 630 may indicate, for example, that aspecific balloon with a specific content should be activated, that alink should be displayed, or that a content within a specific balloonshould be changed as indicated by a respective rule, etc. Furthermore,the actions may indicate how the balloons (or other meta-datainformation) may look like, for example in terms of its shape, color,size, etc.

The output generator 645, or more particularly the intermediate programgenerator 640 of the output generator, receives as an input for eachinputted document version (for example, the versions 660 of thecurrently processed document may be PDF, EXCEL, Word, and HTML), thedocument version itself, the rules associated with the document asdefined by rule editor 620, and the corresponding actions for each ofthe rules as defined by actions editor 630. As will be shown, there maybe two manners of operation in which the editor is used, depending onthe inputted document. If the inputted document (i.e., the document fromwhich the inputted document versions 660 to module 610 were produced) isa full document, for example, a specific bill which includes all thespecific values in all fields, the output 655 from unit 521 is pluralityof ready for operation extended document versions. Such manner ofoperation is useful generally in early stages of the meta-data layerdefinition. If, however, the inputted document (i.e., the document fromwhich the various inputted document versions 660 to module 610 wereproduced) is a template document, for example, a bill template whichdoes not include the specific values for the bill fields (such as thespecific customer name, his address, and all other values), the output656 from unit 521 is a generic, intermediate program.

For the case where the inputted document versions 660 relate to a fulldocument (in contrast to a document template), the operation of theoutput generator 645 is preferably performed in two phases, a firstphase by Intermediate Program Generator 640, and a second phase byVersions Dependent Converter 650. Upon receipt of the document versions(for example, one at a time) from the technology connectors module 610,the defined rules from rules editor 620, and the corresponding actionsfrom actions editor 630, the intermediate program generator 640 producesa generic, intermediate program which describes all the activitiesexpected from the meta-data layer, based on the predefined rules andactions, and with respect to the corresponding document. This program isgeneric in terms of the document versions as it does not relatespecifically to any of the PDF, WORD, EXCEL, or HTML, versions etc. Theprogram is intermediate in terms of its functionality, as it is not thefinal program which is attached to any of the document versions forproducing any version of a final extended document. Said generic,intermediate program 670 as produced by intermediate program generator640 is provided into Versions Dependent Converter 650. VersionsDependent Converter 650 converts said generic, intermediate program toplurality of programs, each relating to a single format version of thedocument. As said, a PDF document needs the program to be coded inJavaScript, HTML needs the program to be coded in another type ofJavaScript, WORD and Excel documents need the program to be coded inVisual Basic. In other words, Versions Dependent Converter 650 producesseveral programs, suitable for all the program versions respectively.The versions dependent converter 650 also attaches respectively each ofthe format dependent programs as produced to its corresponding documentversion, thereby to produce the various final extended documents (i.e.,extended PDF document, extended Word document, extended EXCEL document,extended HTML document, etc.). As said, the two phases of the process asperformed by the output generator 645 enable the production of theplurality of extended documents, while producing a generic, intermediateprogram only once, with no need to produce such program separately foreach format (version) of the document. As said, the above describedtwo-phase process of the output generator 645 is suitable for the earlystages of the editing of the meta-data layer, as it operates on aspecific, full inputted document (although in several inputted formats).The output of the two phase process of module 645 is not suitable forreal time creation process of extended bills, as these bills are basedon templates, to which specific data are fed. For that purpose during alater stage of the editing process, the creator works on a templatedocument for which multiple document versions 660 are inputted to thetechnology connectors module 660 (this may be the same specificdocument, treated as if it was a template). The inputs to the outputGenerator 645 are the same described. However, during said latter mannerof operation, only the first stage (i.e., of the intermediate programgenerator 640) is used. The intermediate, generic program 656, ascreated, is outputted to the meta-data layer processor 520 (FIG. 4). Themeta-data layer processor 520 in turn also comprises versions dependentconverter (not shown) essentially identical to the versions dependentconverter 650 of the meta-data layer editor 521, as described withrespect to FIG. 6B. As previously said with respect to FIG. 4, themeta-data layer processor 520, produces in real time one at a time thevarious customers specific bills (or other documents) from templates,using the data specific to each customer, as stored in database 513.Having a specific bill (or another specific document, as is the case) invarious versions on one hand, and the generic intermediate program 656on the other hand, the versions dependent converter which is within themeta-data layer processor 520 produces the various extended versions ofthe bill (or document). In other words, it produces one at a time aspecific extended bill (or document) in various different formats, eachversion includes attached to it a corresponding program (Java Script forPDF, Java Script, however different from the one of the PDF, for theHTML, Visual Basic for Word, etc.)

FIG. 7 describes the process of producing plurality of extended documentversions as described above with respect to FIG. 6B. The process issimilar to the process of FIG. 3, however, while the process of FIG. 3relates to the production of a single format extended document (in thecase of FIG. 3 an extended PDF document), the process of FIG. 7 relatesto the production of plurality of document versions, in a manner whichis preferable by the process of the present invention. In step 801,plurality of the document versions are produced, for example, PDF, Word,HTML, and EXCEL format versions of the document. Step 802 publishes thedocument in the various versions by performing a process as describedwith respect to units 501, 502, 512, 513, 514, and 516 of FIG. 4, andlater performing “save as” of the published document for eachcorresponding version. The result of the publishing process 802 istherefore plurality of versions of the document, for example, a PDFformat version 803 a, a Word format version 803 b, and other formatversions 803 c. The process is then continues by performing meta-dataediting 810, a process as described above with respect to meta-datalayer editor 521, within meta-data layer manger 600. As mentioned withrespect to FIG. 6B, most of the meta-data editing procedure within step810 is produced only once by producing an intermediate generic program(by converter 640 of FIG. 6B), and which is then converted to pluralityof specific format programs that are then attached to the variousformats document versions 803 a, 803 b, 803 c, etc., to produceplurality of extended documents, extended PDF document 805 a, extendedHTML document 805 b, and extended other format documents 805 c.

While some embodiments of the invention have been described by way ofillustration, it will be apparent that the invention can be carried intopractice with many modifications, variations and adaptations, and withthe use of numerous equivalents or alternative solutions that are withinthe scope of persons skilled in the art, without departing from thespirit of the invention or exceeding the scope of the claims.

1. System for the preparation of an extended, two layer electronicdocument, said extended document having the form of a single packagewhich comprises a text document and a meta-data layer program attachedto it, said system comprises a meta-data layer editor, which in turncomprises: a document connector module for receiving a text document,and for parsing the document to document elements; meta data layereditor for defining rules concerning the content of each meta-data layerelement, rules concerning to the form of appearance of each meta-datalayer element, and action rules concerning conditions for activation ofmeta-data layer elements, wherein meta-data layer elements correspond toselected document elements of said text document; and, program generatorfor generating from said rules an intermediate meta-data layer program;wherein said system further comprises at least one converter forreceiving a copy of said text document and also receiving saidintermediate program from said program generator, and for converting thesame to said two layer extended document.
 2. System according to claim1, wherein said one or more converters are located internal or externalof said meta-data layer editor.
 3. System according to claim 1, whereinwhen a converter is located within said meta-data layer editor, it isused to output an extended document during early stages of the meta-datalayer design.
 4. System according to claim 3, wherein the input to themeta-data layer editor is a full text document.
 5. System according toclaim 1, further comprising a GUI for interfacing with the meta-datalayer editor.
 6. System according to claim 1, wherein said meta-datalayer editor is used off-line by a meta-data layer creator;
 7. Systemaccording to claim 1, which is used for serially preparing plurality ofextended documents one at a time, wherein each document is customerspecific, which further comprises: a document processor for preparingone at a time an original customer specific document, said processorbeing in communication with a customer database and it also receives adocument template, document preparation rules, and additional data, saidoriginal customer specific document being conveyed to alocking-publishing unit; locking-publishing unit for receiving, one at atime, said original customer specific document, and for producing alocked document; a meta-data layer processor for receiving one at a timesaid published locked document and said intermediate meta-data layerprogram, and using a converter, producing said two layer extendeddocument.
 8. System according to claim 7, wherein the converter which isused by the meta-data layer processor for producing said two layerextended document is external to the meta-data layer editor.
 9. Systemaccording to claim 7, wherein the document which is used as an input tothe editor during later stages of the meta-data layer design is atemplate locked document.
 10. System according to claim 1, for producingplurality of format versions of extended documents, wherein each of theone or more converters, whenever used, receives said intermediateprogram and plurality of format versions of documents, and it convertsthem to plurality of format versions two layer extended documents, allabiding the same set of meta-data rules, for correlated objects withinthe various versions.
 11. System according to claim 1, wherein themeta-data layer within the extended document is a program coded in asoftware language which is suitable for activation by a correspondingviewer which displays said two layer documents.
 12. System according toclaim 11, wherein when the extended document is a PDF document, saidsoftware language is a first type of Java Script, when the extendeddocument is an HTML document, said software language is a second type ofJava Script, when the extended document is a WORD document, saidsoftware language is Visual Basic, and when the extended document is ofanother format, said software language is in another language which issuitable for activation by the viewer.
 13. System according to claim 7,wherein the rules and actions together determine customer specificconditions for activation and corresponding content of each meta-datalayer element, when the extended document is displayed by acorresponding viewer.
 14. System according to claim 1, wherein themeta-data layer elements have a form of pop-up balloons.
 15. Systemaccording to claim 7, wherein each of the extended documents is conveyedto a corresponding customer by email, and is viewed by the customer bymeans of a corresponding viewer.
 16. System according to claim 7,wherein each of the extended documents is saved within extendeddocuments database at the company, and only a link to the respectivedocument is sent to the customer by mail.
 17. System according to claim7, wherein the extended document is a bill, and wherein the documentprocessor is a bill processor.
 18. System according to claim 1, whereinthe meta-data layer of the extended document displays to the user whoviews the document a corresponding indicator, which when the user putshis mouse marker next to said indicator, the activation of acorresponding meta-data layer element occurs.
 19. System according toclaim 1, wherein the extended document is a PDF extended document. 20.System according to claim 1, wherein the extended document is a WORDextended document.
 21. System according to claim 1, wherein the extendeddocument is an HTML extended document.
 22. System according to claim 1,wherein the extended document is an EXCEL extended document.
 23. Systemaccording to claim 7, wherein when the extended document is a two-layerPDF document, the locking-publishing unit is a PDF distiller.
 24. Systemaccording to claim 7, wherein said meta-data layer editor and saidmeta-data layer processor are included within a meta-data layer manager.25. System according to claim 1, wherein upon viewing of said extendeddocument at a user viewer, activating also said meta-data layer, andselectively displaying said meta-data elements to the user.